In the field of communications network management a lot of management resources are expended in performing configuration management, and in particular for configuring routers in packet-switched communications networks.
Routers are Open Systems Interconnect (OSI) Layer-3 (L3) communications network entities directing packets between source communications network nodes and destination communications network nodes in packet-switched communications networks. A typical communications network deployment employs a multitude of routers of various makes, types and software releases.
By far, the most common method of configuring a router includes employing Command Line Interface (CLI) commands. Unfortunately CLI command sets are not standardized and may even vary across a single vendor's equipment portfolio. As a result, a lot of resources are being expended in training network management personnel to be adept at configuring any and all router makes and types, i.e. mastering a huge CLI command set the complexity of which increases with each router software release. Despite large amounts of resources being expended in training network management personnel gaining experience in configuring routers, human error is a further factor which can not be ignored particularly when it comes to configuring high capacity routers.
To alleviate the problem of configuring routers, some communications network operators employ a group of highly trained analysts to write full equipment configuration CLI scripts for each one of a variety of L3 equipment employed in a managed communication network. Such complex CLI scripts are then made available to less highly trained. personnel, at least with respect to CLI configuration of L3 equipment, who execute the scripts on the various L3 equipment as these are required to be configured. Although this approach reduces configuration costs by utilizing the highly trained analyst expertise only for CLI script creation, it has a disadvantage in terms of script re-use. Specifically, the entire CLI scripts must often be customized, by highly trained analysts who are familiar with software release specific CLI command sets/parameters, because typically some of the CLI commands employed are, and have parameters that are, software release specific. Manually customizing the entire CLI scripts for each router software release is not the most efficient way to re-use the CLI scripts as it is time consuming and error prone.
An alternative to using scripts is to fully model a router and associated L3 objects such as, but not limited to: interfaces, routing protocols, and Internet Protocol (IP) links, etc. associated therewith; and then use a Network Management System (NMS) to configure the modeled routers and objects associated therewith. This approach suffers from a disadvantage of not allowing for easy configuration of new managed objects because to model the new managed objects and their interactions requires changes to the NMS software.
Modifying NMS software to support the introduction of new managed objects via updated router operating software releases of various routing equipment vendors at various times, is time-consuming and costly because of the workload required to implement such changes, testing and distribution of the updated NMS software. Furthermore, desiring to keep the number of NMS software updates to a manageable level would mean that there would always be a lengthy time lag in providing support for the new managed objects between the introduction of the new managed objects by router equipment vendors and those supported by the NMS.
Developments towards these ends include a prior art U.S. Pat. No. 6,463,528 entitled “Method and Apparatus for Simplifying the Configuration of Several Models of Customer Premise Equipment” which issued on Oct. 8, 2002 to Rajakarunanayake et al. which describes automatically configuring various makes and models of routers with Internet Protocol (IP) addresses and IP masks at install time. Rajakarunanayake et al. teach the use of a single parameterized script that is automatically populated with stored and user-specified parameters. Employing a single configuration script may be adequate for simple router configurations such as providing a single setting, however in accordance with the Rajakarunanayake et al. teachings large complex scripts have to be employed in configuring other then a single setting on a router. Writing complex large configuration scripts must have hard-coded therein correct sequencing of CLI commands, however the opportunities for re-using such complex large scripts are reduced.
Therefore, means for easily and efficiently configuring numerous routers of various makes, models, and software release is required.